Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976

Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976

Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976

Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976

Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976

Guard against non-monomorphized type_id intrinsic call

This PR checks whether the type is sufficient monomorphized when calling type_id or type_name intrinsics. If the type is not sufficiently monomorphized, e.g. used in a pattern, the code will be rejected.

Fixes rust-lang#73976

…arth

Rollup of 9 pull requests

Successful merges:

 - rust-lang#73783 (Detect when `'static` obligation might come from an `impl`)
 - rust-lang#73868 (Advertise correct stable version for const control flow)
 - rust-lang#74460 (rustdoc: Always warn when linking from public to private items)
 - rust-lang#74538 (Guard against non-monomorphized type_id intrinsic call)
 - rust-lang#74541 (Add the aarch64-apple-darwin target )
 - rust-lang#74600 (Enable perf try builder)
 - rust-lang#74618 (Do not ICE on assoc type with bad placeholder)
 - rust-lang#74631 (rustc_target: Add a target spec option for disabling `--eh-frame-hdr`)
 - rust-lang#74643 (build: Remove unnecessary `cargo:rerun-if-env-changed` annotations)

Failed merges:

r? @ghost

Improve diagnostics when constant pattern is too generic

This PR is a follow-up to PR rust-lang#74538 and issue rust-lang#73976

When constants queries Layout, TypeId or type_name of a generic parameter, instead of emitting `could not evaluate constant pattern`, we will instead emit a more detailed message `constant pattern depends on a generic parameter`.

…li-obk

make `ConstEvaluatable` more strict

relevant zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/.60ConstEvaluatable.60.20generic.20functions/near/204125452

Let's see how much this impacts. Depending on how this goes this should probably be a future compat warning.

Short explanation: we currently forbid anonymous constants which depend on generic types, e.g. `[0; std::mem::size_of::<T>]` currently errors.

We previously checked this by evaluating the constant and returned an error if that failed. This however allows things like
```rust
const fn foo<T>() -> usize {
    if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
        std::mem::size_of::<T>()
    } else {
        8
    }
}

fn test<T>() {
    let _ = [0; foo::<T>()];
}
```
which is a backwards compatibility hazard. This also has worrying interactions with mir optimizations (rust-lang#74491 (comment)) and intrinsics (rust-lang#74538).

r? `@oli-obk` `@eddyb`